Basic API docs (IVS-319) #202
Conversation
…l-to-company IVS-412 - Link AuthoringTool to Company
…tool-evaluation IVS-425 - Unified authoring tool evaluation
…t_Admin_Emails IVS-395 - Include environment in admin emails (low prio)
…vements IVS-427 - Django Admin improvements
…_for_Users IVS-37 - Disable initial emails for end users
…ription-url IVS-429 - Fetch correct description (url)
…y-assign-Users-to-a-Company-based-on-Company-email-pattern(s) IVS-417 - Manually link users to selected Companies based on email pattern(s)
IVS-552 - Include feature tags in documentation
IVS-520 (&IVS-543) - Orchestration of syntax and header tasks
…ormatting fix formatting for ALS017 results (IVS-560)
…combine IVS-567 fix syntax status combine
Existing reports pre-signature feature fail to render
…nder IVS-559 - Existing reports pre-signature feature fail to render
- add API quick start - update copyright year and version number - add link to python behave - remove error codes in Appendix (IVS-319)
| author = 'buildingSMART International' | ||
| release = '0.6' | ||
| release = '0.7.7' |
There was a problem hiding this comment.
Added a note in the release management docs to update this version with every deployment to prod
|
I'm missing a bit of context, but why do we still have a gh-pages branch? These days you can deploy everything (every branch, every subfolder). |
|
@aothms for CI/CD we have a Github Action that publishes the updated docs on each merge to |
Ok, if you're still happy than no reason to change, just this merge PR made me wonder if a folder on the dev/main branch to deploy from (can still be decoupled from actual releases with separate action) isn't more convenient. |
Note: The majority of commits in this PR come from merging
developmentinto `docs/gh-pages'.The specific content to review is scoped purely to the documentation - see 378aea6.